The corresponding marker is documented in 18477-1, JPEG XT part 1. So much for the question "where is this defined". The confusing part here is that neither JPEG codestreams nor JPEG-LS codestreams define a color space they operate in. Actually, codestreams never do, they just reconstruct samples values bare any color information. This has been always true for all JPEG standards to date. It needs a file format to give these sample values a meaning. Now, the even more confusing part is that JFIF (or rather ISO/IEC 10918-5) defines a file format, and this "file format" is almost identical to the codestream, just by a marker. Within JPEG XT, the marker operates on codestream level (no color space either!) and disables a normative part of a JPEG XT decoder (but not a JPEG decoder), which is a color decorrelation transformation that is "by accident" identical to the YCbCr decorrelation transformation of JFIF. It reflects by this normative part a "common practise" of existing JPEG decoders to interpret the samples of the codestream relative to the 601 RGB primaries rather than relative to the 601 YUV luma/chroma coordinates, so in that sense this specification "makes sense" as it happens to do "the right thing". IOW, it runs the transformation as part of the decoder, and gives sample values that, bare any other color space information, happen to be in 601 RGB. With the marker present, things also work. For JPEG-LS, things are not any different than for JPEG XT, there is only a codestream for it, and samples have no meaning. If you run the LS decoder without further information, it also "assumes" that the encoded samples are relative to YUV colors, and thus a tranformation is run, that now reflects a color space information. Unfortunately, it is lossy. Thus, what the "-c" flag of the decoder does is that it tells the decoder "sorry, but sample values are not relative to 601 YUV, but relative to 601 RGB", i.e. it adds a color space information to the codestream which, actually, does not have any. The morale of the story is that you should really embed codestreams into a file format, as it is the purpose of the file format to unambigiously define what the color space should be. For JPEG, the codec supports the JFIF file format, which is standardized in 10918-5. For JPEG-LS, there is no file format support in the code. However, ISO/IEC 15444-2 provides a file format, JPX namely, that could encapsulate JPEG-LS, and then would define a color space. Thus, you need to tell the codec explicitly what the color space should be. Sorry, it's a long and complicated story.

Am 06.03.22 um 22:43 schrieb Valerii Zapodovnikov:

10918-6 is JPEG, not JPEG-LS. One can possibly apply the same reasoning to JPEG-LS (this is a bit stretchy, LS is really a different spec). Anyhow, this software currently does not implement -6 as such. For that, much more would need to be done. It would require a color management module to properly handle ICC profiles (another common marker), and color specification boxes (borrowed from other JPEG norms, and put into JPEG XT). I'm not sure this software is the right place for it. As stated before, this would be rather the job of something larger that would use the services of tinycms, for example (a library coming from the color consortium, they deal with color and have the right tools, not the limited ones of JPEG). This software is in the "long tradition" of JPEG being color blind, and putting that load on the shoulders of somebody else. (-; Greetings, Thomas